Complex software like applicant's SAP R/3 Release 4.5 (SAP) requires customization, e.g. selection of predefined functionality, and adaptation, e.g. addition of or amendment to functionality, as well as other servicing like program and data updates, cf. “SAP System Landscape Optimization” by A. Schneider-Neureither (Ed.), SAP Press, 2004, ISBN 1-59229-026-4, and “SAP R/3 Änderungs-und Transportmanagement” by Metzger and Rohrs, Galileo Press GmbH, Bonn, Germany, 4th reprint 2004, ISBN 3-934358-42-X.
Before such servicing may be performed, however, it has to be assured that the customizations, adaptations, program and data updates etc. are free of errors and integrate flawlessly into the software and data environment. In a factory for instance servicing errors are bound to result in costly workflow disruptions due to software malfunction or data corruption. Apart from the servicing side, other use of the software like training of new or inexperienced users may also result in a disruption of the productive system.
Such complex software may therefore be implemented in form of separate logical systems that together form a system landscape. A typical implementation of the aforementioned SAP software for instance may, cf. FIG. 1, comprise a development system 101 for customizing and development work, a quality assurance system 102 for testing functionality using representative test data, a training system 103 for training new users, and several productive systems 104, e.g. each for a different factory, for actual productive use. Other or additional users and systems may be defined according to the particular requirements.
The logical systems are identical in large parts, function autonomously and may be run on a single computer. The quality assurance system 102 for example resembles the productive system 104 in that it provides all the functionality, its present data and additionally special test data. New customization settings or adaptations may thus be thoroughly tested in the quality assurance system 102 without jeopardizing the productive system 104. Likewise, the training system 103 resembles the productive system 104 in that it provides some of the functionality and special test data. A new user using the training system 103 may thus become accustomed to the functionality and observe the effect of his actions, albeit without disturbing the productive system 104.
Software services that have been tested and approved in one system may be forwarded to subsequent systems via logical directional transport paths 105. For instance, a service approved in development system 101 is forwarded to the quality assurance system 102, and upon approval in the quality assurance system 102 further forwarded simultaneously to the training system 103 and both productive systems 104.
Servicing is often performed on a software service project basis. A software service project like adaptation of the software to new legislation may require servicing of a selection of systems of the system landscape only, e.g. the systems in one country only. As all systems simply forward the imported services to all other systems connected thereto, the operators of the systems that do not require servicing have to manually reject each and every service that is not intended for their system. This is time consuming and bears the risk of errors, in particular given the considerable number of services that are typically required during the lifetime of a project. An automated way presently is to change system changeability parameters of each system on a project basis, e.g. to specify in each system whether it accepts services corresponding to a particular project. This, too, is time consuming and bears the risk of errors as it requires authorized access to and configuration of each system.
The operator also has to assure that the services are imported in the correct order. The importance of the correct order is illustrated in FIG. 2a and FIG. 2b. An original version 201 of the software and data is first modified by a first service 202, resulting in modified version 203, and subsequently by a second service 204, resulting in modified version 205, cf. FIG. 2a. However, if the second service 204 is imported before the first service 202, the original version 201 is changed into modified version 206 by the second service 204 and subsequently into modified version 207 by the first service 202, cf. FIG. 2b. The modified versions 205 and 207 differ and the version 207 will not perform as intended.
In view of the fact that an SAP R/3 implementation may comprise dozens of systems and require thousands of services per month during project development and implementation, the operator time required becomes considerable as does the risk for errors to occur.